Payment system

ABSTRACT

Embodiments of the invention provide a method of processing payment authorization requests for payment transactions to be conducted via a data communications network; the payment authorization requests are conducted as a result of orders by financial account holders via a plurality of different online merchant systems, and the financial account holders hold accounts with a plurality of different issuing banks. These embodiments of the invention provide a means of identifying an issuing bank from a plurality of issuing banks as one which is to be utilized in a given transaction and facilitate a user specifying, in real time in relation to the given transaction, a particular bank account that is to be used to deduct funds for that transaction.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.13/178,431 filed on Jul. 7, 2011 which is a continuation under 35 U.S.C.§ 120 of International Application No. PCT/EP2010/050158, filed on Jan.8, 2010, and published in the English language as InternationalPublication No. WO 2010/079216, which claims priority to U.S.application Ser. No. 12/416,902, filed on Apr. 1, 2009, and also claimspriority to GB Application No. 0900223.9, filed on Jan. 8, 2009. Each ofthe above-referenced patent applications is hereby incorporated byreference in its entirety.

BACKGROUND OF THE INVENTION Field of the Invention

The present invention relates to a payment system and method ofprocessing payment authorization requests for payment transactions to beconducted via a data communications network, and is particularly, butnot exclusively, suited to payment authorization requests beingconducted as a result of orders by financial account holders via aplurality of different online merchant systems.

Description of the Related Art

Users are increasingly encouraged to purchase goods online, i.e. via theInternet and associated technologies. Generally speaking, existingonline payment systems fall into one of four types of arrangement: in afirst type of arrangement, an online merchant system collects paymentdetails from a financial instrument holder, otherwise known as a buyeror cardholder, without the buyer dealing directly with any other entitythat may be involved in the transaction, and the online merchant systemsends the transaction details directly to their acquiring bank system.In a second type of arrangement, the online merchant system collectspayment details from a buyer without the buyer dealing directly with anyother entity that may be involved in the transaction, and the onlinemerchant system sends the transaction details to an online merchantInternet Payment Service Provider (merchant IPSP system) which processespayment authorizations on behalf of the merchant. The merchant IPSPsystem subsequently transmits the details to the online merchant'sacquiring bank system; the details may be transmitted directly to theacquiring bank or to a payment processor which acts on behalf of theacquiring bank. Examples of merchant IPSP systems which provide supportfor this second type of arrangement include the Protx™ Veri-SecurePayment system (VSP). An advantage of using a payment gateway such asthe afore-mentioned merchant IPSP system is that the merchant IPSPsystem can provide one or more additional various transaction processingfunctions, for example settlement, handling of chargebacks, handling ofrefunds, and transaction reporting, on behalf of the online merchant. Inthe settlement procedure, the merchant IPSP system submits all theonline merchant's approved authorizations collected over a given period,in a “batch”, to the online merchant's acquiring bank system forsettlement. A chargeback is a reversal of a payment card transactioninitiated by the buyer or the bank that issued the card used in thepurchase. This differs from a refund, which is agreed to and initiatedby the online merchant, via the merchant IPSP system. Transactionreporting involves providing an overview reporting function foraccumulated transactions which have been authorized and optionallysettled via the merchant IPSP system, so that a merchant can for exampleselect a date range and see an overview relating to all transactionsconducted within the selected date range. A merchant IPSP system mayprovide an online merchant with a secure online website whereby toapprove chargebacks, initiate refunds and/or view transaction reports asdescribed.

In a third type of arrangement the online merchant system redirects thebuyer to an alternative payment system website with which the buyerinteracts in order to complete the transaction. The alternative paymentsystem interacts directly with the user who provides payment to thealternative payment system either directly from their bank account orvia a mechanism such as a payment card. Where a payment card from aconventional payment scheme is used the alternative payment systemperforms the role of the merchant in the conventional payment system,submitting a payment demand through an acquiring system. Payment fromthe user is made to the alternative payment system. The alternativepayment system is then responsible for any reimbursement of themerchant. In a second case, the alternative payment system can, ineffect, behave as a conventional clearing house, funding a user'saccount within the alternative payment system from the user's actualissuing bank account by directly debiting their account. The alternativepayment system subsequently ensures payment is sent to the merchant'sissuing bank account, usually through a conventional clearing house.This merchant bank account may or may not be the same as their accountheld with their conventional acquiring system. Thus most of the timepayment systems of the third type act as the intermediary to take actualfunds from the user and pass them to the merchant, most usually via theconsumer's and merchant's individual bank accounts, potentially holdingon to those funds as they pass through accounts held by the paymentsystem; an example of this third type of payment system includes thewell-known PayPal™ payment system. Such a payment system may also havethe capability to operate as a conventional IPSP, for example byproviding associated online payment handling services. Whilst this typeof payment system relieves the need for the user to set up individualpayment accounts on a per online merchant basis, the user has arelationship with the alternative payment system and not with the onlinemerchant system; this gives rise to several notable disadvantages:firstly the online merchant neither receives payment directly from anacquiring bank nor can avail itself of a payment-scheme based guaranteeof payment, because for these transactions there is no directrelationship between the merchant and a card payment scheme. Secondly,for transactions effected via card payment the buyer does not havevisibility of the individual online merchant from whom the product wasbought (instead the card statement identifies the alternative paymentsystem entity). Thirdly, the buyer is not protected by the card scheme'srules and may not be protected by any applicable consumer protectionbecause the transaction is with the payment system, and not with theonline merchant system

When the user interacts solely with the merchant system, the merchantsystem typically obtains payment card data, bank account informationand/or other financial data from the buyer. The merchant then passesthis information either directly or via a payment gateway provided by amerchant IPSP system, to an acquiring bank processing system. Eachmerchant system is assigned a merchant account identifier by anacquiring bank, and this account identifier is used to identify themerchant to the acquiring bank when requesting authorization of atransaction. This requires each merchant system to implement its ownpayment processing capability, isolated from other merchants; as aresult a buyer is required to provide their payment informationseparately for each merchant. Thus, for each new merchant that a buyerinteracts with, the risk of exposure, misappropriation and/or fraudulentuse of the buyer's financial data increases.

These known payment systems require that the user enters their accountdetails on a per transaction basis or upon registration with themerchant IPSP, or alternative, non-IPSP, payment system; thus the useris the sole point of contact for procuring the relevant payment details.Whilst this is an accepted approach, account identifiers tend to bedifficult to remember, and as a result users can generally only makepurchases and/or sign up to payment services and merchant sites whenthey have their account details with them at the relevant point in time.

In a fourth type of arrangement of a payment system, an additionaloption is provided whereby a buyer is able to select to proceed topayment via their issuing bank, which provides an online banking websitefor such purposes. However, in this case the online merchant, or themerchant IPSP system acting on their behalf, needs to interface with theissuing bank system and moreover, the payment process, once transferredto the issuing bank, proceeds as a bill-payment type transfer directlyfrom the user's transactional account (i.e. a current account orchecking account) held by the issuing bank system. Hence, the fourthtype or arrangement is not capable of providing the transactionprocessing functions available from existing merchant IPSP systems orfrom existing card scheme systems (such as Visa™ and MasterCard™)

SUMMARY

In accordance with at least one embodiment of the invention, systems andsoftware are provided for a method of processing payment authorizationrequests for payment transactions to be conducted via a datacommunications network, as specified in the independent claims. This isachieved by a combination of features recited in each independent claim.Accordingly, dependent claims prescribe further detailed implementationsof the present invention.

More particularly, aspects of the invention provide a method ofprocessing payment authorization requests for payment transactions to beconducted via a data communications network, the payment authorizationrequests being conducted as a result of orders by financial accountholders via a plurality of different online merchant systems, whereinthe financial account holders hold accounts with a plurality ofdifferent issuing banks, the method comprising conducting an accountidentification procedure comprising: identifying, from said plurality ofdifferent issuing banks, an issuing bank associated with a financialaccount holder; on the basis of said identification of the issuing bank,retrieving issuing bank transmission data to enable the transmission ofaccount identification request data, said issuing bank transmission databeing dependent upon the identified issuing bank and identifying aselected account identification system associated with the identifiedissuing bank; on the basis of the retrieved issuing bank transmissiondata, transmitting an account identification request for use in theauthorization of at least one payment transaction, said at least onepayment transactions being initiated as a result of a financial accountholder conducting at least one order via at least one online merchantsystem; and receiving an account identification response in response tothe account identification request, said account identification responseidentifying a financial account identity capable of being used in saidat least one payment transaction.

Thus embodiments of the invention provide a means of identifying anissuing bank from a plurality of issuing banks as one which is to beutilized in a given transaction. Embodiments of the invention provide ameans for a user to specify, in real time in relation to the giventransaction, a particular bank account that is to be used to deductfunds for that transaction. Preferably the user is authenticated inrelation to their account, and thus provides an improvement over knownsystems in which a user has to either send payment details to a merchantsystem or provide details in advance of the transaction, e.g. to a thirdparty entity to whom the user has previously authorized to handle thepayment on their behalf. It is to be understood that by issuing bank ismeant a bank that holds an account on behalf of a user; that account mayor may not be accompanied by a payment card, and indeed embodiments ofthe invention apply equally to users having accounts with their issuingbanks for which cards are not issued. In general terms the issuing bankcould be considered a paying entity (the payer) in the paymenttransaction.

In one arrangement the method further comprises, after receiving saidaccount identification response: a) generating a payment authorizationrequest comprising transaction data including: i) a financial accountidentity to be used in a payment transaction by the financial accountholder; ii) a merchant identity, associated with a first onlinemerchant, as the payment transaction beneficiary; and iii) transactiondetail including a payment amount; and b) transmitting said generatedpayment authorization request for subsequent processing by an acquiringbank payment processor system responsible for processing paymentauthorizations for an acquiring bank with which the first onlinemerchant is associated

This enables the financial account identity to be coupled with arequested transaction as part of an end-to-end process, and has thebenefit of reducing the risk of transaction details being separated fromthe payment details.

Accordingly, the payment authorization request is preferably generatedin response to receiving said account identification response.

Embodiments of the invention enable generation of a plurality of paymentauthorization requests including the same financial account identity: aseparate account identification procedure can be conducted for eachpayment authorization request, which involves transmitting a saidaccount identification request and receiving a said accountidentification response, prior to the generation of each of said paymentauthorization requests. In this case the method can comprise generatinga plurality of payment authorization requests including the samefinancial account identity, and for each of said plurality of paymentauthorization requests, holding said financial account identity, suchthat only a single account identification procedure, which includestransmitting a said account identification request and receiving a saidaccount identification response, is required for all of said pluralityof payment authorization requests. This arrangement has the advantage oflimiting use of bandwidth required to communicate with the identifiedissuing bank.

In a preferred embodiment the data communications network comprises aplurality of different merchant Internet Payment Service Provider(merchant IPSP system) systems. Each of said merchant IPSP systems isarranged to transmit payment authorization requests to at least one of aplurality of acquiring bank payment processor systems; each of saidplurality of acquiring bank payment processor systems is responsible forprocessing payment authorizations for at least one acquiring bank; andeach of a plurality of online merchants is associated with one of saidplurality of merchant IPSP systems. In this arrangement the methodcomprises retrieving merchant IPSP system transmission data to enablethe transmission of payment authorization request data to a selectedmerchant IPSP system associated with the first online merchant, and onthe basis of the retrieved merchant IPSP system transmission data,transmitting the generated payment authorization request to the selectedmerchant IPSP system. A further payment authorization request may thenbe generated and transmitted to an acquiring bank payment processorsystem responsible for processing payment authorizations for theacquiring bank with which the first online merchant is associated. Amerchant IPSP system provides a system that passes card data,authorization requests, and authorization responses over the Internetusing encryption technology, and thus enhances the security of a givenpayment authorization request.

The method preferably comprises receiving a merchant identity from thefirst online merchant system, the merchant identity included in thegenerated authorization request being generated on the basis of thereceived merchant identity. Thus it is the merchant account identifierthat is transmitted to the acquiring bank. As a result the relationshipfor such transactions is between the buyer and the online merchant, withthe resulting benefit that the buyer is protected by the card scheme'srules and by any applicable consumer protection

In a particularly preferred embodiment the method is conducted by atrusted intermediary system, the method comprising said trustedintermediary system receiving from online merchant systems responsiblefor originating payment authorization requests for online merchants,payment authorization requests relating to authorization of paymenttransactions, said received payment authorization requests beinginitiated as a result of financial account holders conducting an ordervia the online merchant systems. Having a centralized entitycoordinating the various communications has benefits of scalability: inparticular the account identification procedure can be conducted by saidtrusted intermediary system in response to receiving a said paymentauthorization request from an online merchant system; the trustedintermediary system can receive a payment authorization response, and inresponse thereto to transmit a payment authorization response to saidfirst online merchant system.

Furthermore, the trusted intermediary system can provide a registrationinterface for online merchants whereby the online merchants can registera merchant IPSP system with which they are associated, and the step ofretrieving transmission data to enable the transmission of paymentauthorization request data to the selected merchant IPSP systemassociated with the first online merchant can be conducted on the basisof the merchant IPSP system registered by the first online merchant.

When transactions which are authorized using the system of the presentinvention are processed by the merchant IPSP system, merchant IPSPfunctions relating to these transactions may be accessed by the onlinemerchant using an interface common to different transaction types. Thesetransaction types may include both transaction types for which paymentauthorization requests originate via the trusted intermediary system andother, separately authorized, transaction types which may be processedby the IPSP on behalf of the merchant without passing via the trustedintermediary system. This common interface may comprise a secure onlinewebsite.

For users having a plurality of different financial accounts, the methodcomprises receiving data indicating a selection, by the financialaccount holder, between a plurality of such different financial accountsfor use in the payment transaction, and retrieving a financial accountidentity on the basis of said indicated selection. Conveniently this isfacilitated via an account selection interface for a financial accountholder whereby the financial account holder can select a financialaccount identity.

The step of retrieving issuing bank transmission data can compriseretrieving a network address for the selected account identificationsystem; in some arrangements the network address can be transmitted to afinancial account holder to enable the financial account holder toaccess said selected account identification system. Specifically, thefinancial account holder is able to conduct an identification procedureby providing identifying information to said selected accountidentification system. Further, in such arrangements the accountidentification response is received by the financial account holder fromsaid selected trusted intermediary system in response to authenticationof the financial account holder by the selected account identificationsystem.

In some embodiments the financial account identity comprises a PrimaryAccount Number (PAN) associated with said financial account holder—forexample in the form of a payment card number. Alternatively thefinancial account identity can comprise an International Bank AccountNumber (IBAN), or alternatively a bank identifier, which is preferablyan international bank identifier such as country code and sort code, orBIC code, and an account number. However, a PAN format is preferredsince it is in the format which is processed using existing card schemepayments.

According to a further aspect of the present invention there is provideda method of authorizing payment transactions conducted via a datacommunications network, a payment transaction being conducted as aresult of an order by a financial account holder via a merchant dataprocessing system, the method comprising accessing stored online bankingauthentication details for an online banking authentication processwhereby a financial account holder is able to access an online bankingapplication, the online banking application relating to at least onefinancial account holder financial accounts, wherein the methodcomprises: receiving a request relating to authorization of a paymenttransaction, said request being initiated as a result of a financialaccount holder conducting an order in a merchant data processing system;in response to receiving said request, conducting a paymentauthentication process in which the financial account holder providesauthentication details corresponding to the stored online bankingauthentication details; in response to verification of the enteredauthentication details against the stored online banking authenticationdetails, retrieving a primary account number (PAN) for use in paymentprocessing; transmitting said retrieved primary account number (PAN) toan Internet Payment Service Provider (merchant IPSP system) system foruse in authorization of the payment transaction.

In some arrangements the primary account number (PAN) is generated forone-time use only. The payment authentication process can be conductedby an issuer banking data processing system, while the method can beconducted at least in part via a transaction processing data processingsystem, separate from said issuer banking data processing system. Forexample, the method can comprise the issuer banking data processingsystem transmitting said retrieved primary account number (PAN) to saidtransaction processing data processing system in response toverification of the entered authentication details, and said transactionprocessing data processing system transmitting said retrieved primaryaccount number (PAN) to a payment processing data processing system.

In the event that the primary account number (PAN) is stored by thetransaction processing data processing system, the method comprisesretrieving said primary account number (PAN), and transmitting saidretrieved primary account number (PAN) to a merchant IPSP system inresponse to verification of the entered authentication details.

It is to be understood that the terms “online merchant”, “merchant IPSPsystem”, “trusted central intermediary system”, “transaction processingdata processing system” and “acquiring bank payment processor system”refer to logical components. As such, each system may be embodiedphysically separate from one another or physically connected to one ormore other system. For example, in arrangements where a givenorganization hosts the merchant IPSP system and the online merchant, thecomponents could be physically located on the same network or evenintegrated as part of a single system. Further, where a givenorganization hosts the merchant IPSP system and acquiring bank paymentprocessor system, the components could be physically located on the samenetwork or even integrated as part of a single system. Further still, asingle organization could host the online merchant, the merchant IPSPsystem and the acquiring bank payment processing system. Thus,embodiments of the invention encompass arrangements in which thefunctions performed under the role of the IPSP can be carried out by anorganization that is also the merchant and/or also the acquirer.

According to further aspects of the invention there is provided atrusted intermediary system in communication with an online merchantsystems and with a plurality of issuing banks, each having an accountidentification system associated therewith, said trusted intermediarysystem being arranged to conduct the afore-mentioned accountidentification procedure. Further, there is provided an online merchantsystem in communication with a trusted intermediary system and aplurality of merchant IPSP systems, said online merchant system beingarranged to conduct the afore-mentioned online merchant system steps.Further still there is provided a merchant IPSP system in communicationwith a trusted intermediary system and a plurality of online merchantsystems, said merchant IPSP system being arranged to conduct theafore-mentioned merchant IPSP system steps. Aspects of the inventionalso provide software distributed between the various systems, suitablyconfigured to perform the afore-mentioned method.

Further features and advantages of the invention will become apparentfrom the following description of preferred embodiments of theinvention, given by way of example only, which is made with reference tothe accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram showing a payment system according to afirst embodiment of the invention;

FIG. 2 is a schematic diagram showing a payment system according to asecond embodiment of the invention;

FIG. 3 is a schematic diagram showing a payment system according to ayet further embodiment of the invention;

FIG. 4 is a schematic flow diagram showing the flow of data during useof the payment system of FIG. 3 according to an embodiment of theinvention;

FIG. 5 a is a schematic block diagram showing components of the trustedintermediary system according to an embodiment of the invention;

FIG. 5 b is a schematic block diagram showing components of the trustedintermediary within which the trusted intermediary system according toan embodiment of the invention is implemented;

FIG. 6 is a schematic timing diagram showing the flow of messagesassociated with account selection according to an embodiment of theinvention;

FIGS. 7-10 are schematic timing diagrams showing alternative messageflows to that shown in FIG. 6 ; and

FIG. 11 is a schematic flow diagram showing alternative, end-to-end,payment selection paths, which employ a further embodiment of theinvention.

DETAILED DESCRIPTION

As described above, embodiments of the invention are concerned with apayment system and method, specifically a system and method ofprocessing payment authorization requests for payment transactions to beconducted via a data communications network, the payment authorizationrequests being conducted as a result of orders by financial accountholders, via a user system such as a personal computer or othercomputing device, via a plurality of different online merchant systems.

FIG. 1 shows a payment system according to a first embodiment of theinvention, in which the financial account holder, making use of usersystem U1, holds accounts with a plurality of different issuing banks 2a, 2 b; these issuing banks include banks that assign an appropriatedebit card number to enable the payment to be routed back to theconsumer's current account via the card scheme system to a user andassume the primary liability for the user's capacity to settle any debtsincurred with the card. However, and as described above, this case ofthe issuing bank assigning a card to the user in conjunction with theuser's bank account is to be considered a non-limiting example of anapplication of embodiments of the invention. As can be seen from theFigure, the user system U1 is connected via data communications linksvia which the financial account holder is able to enter into atransaction with one of a plurality of online merchant systems 1 a, 1 b,1 c when purchasing goods over the Internet. The online merchant systemsare equipped with software that enables the user to select a paymentmethod for purchase of their selected goods, and in embodiments of theinvention, the payment selection software includes an option for theuser system U1 to access a trusted intermediary system 4 whereby thefinancial account holder is able to specify a particular bank accountfrom which payment is to be deducted.

In a preferred arrangement, selection of this option triggers the onlinemerchant system 1 a to redirect the user to the trusted intermediarysystem 4, this then commencing an account identification procedureinvolving the trusted intermediary system 4, the user U1 and one of theplurality of issuing banks 2 a, 2 b. Thus selection of the bank accountoption from the merchant's online shopping software effectively causesthe user U1 to be redirected and communicate with the trustedintermediary system 4 and the relevant issuing bank 2 b; theseredirection steps are indicated by means of a dashed line in the Figure.The financial account holder, via the user system U1, is required tospecify, for example via selection from a drop-down list or by enteringdata directly, an identifier of the issuing bank from which payment isto be deducted, e.g. in the form of country code and bank name (e.g.“GB” and “HSBC”) or a code such as Bank Identifier Code (BIC), SWIFTcode, or a Bank Routing Number (also known as an American BankingAssociation (ABA) Number), whereupon the trusted intermediary system 4identifies the relevant issuing bank system 2 b (e.g. by lookup of atable holding online banking web site details for a range of issuingbanks) and redirects the user system U1 to communicate therewith. In anInternet-based arrangement this redirection may involve directing theuser's browser to a web server associated with the issuingbank-conventionally referred to as an online banking login page. Thefinancial account holder, via the user system U1, then logs into theironline bank account in the normal way, sending an account identificationrequest for use in the authorization of at least one paymenttransaction.

As will be described in more detail below with reference to FIG. 6 , theredirection occurs under the control of the trusted intermediary system4, which is to say the web page that is displayed to the user iseffectively encapsulated within a web page controlled by, or issued inassociation with, the trusted intermediary system 4. As a result, uponselection of an account from which payment is to be deducted, thetrusted intermediary system 4 subsequently receives, from the issuingbank 2 b, an account identification response identifying a financialaccount identity capable of being used in the transaction.

This account identification response can comprise a Primary AccountNumber (PAN) normally associated with the debit card linked to theuser's account; it will therefore be appreciated that embodiments of theinvention are particularly well suited for situations in which the userU1 desires payment to be effected from a payment instrument (typicallycards and accounts). Once received by the trusted intermediary system 4,the PAN is then transmitted, in the form of a payment authorizationrequest, to the acquiring bank 5 processor, or beneficiary, associatedwith the merchant 1 a, per conventional methods in which the user hasentered payment details into the merchant's online system. The PAN isaccompanied by the transaction information and the merchant's accountidentifier, and the card scheme system 7 routes the transaction to thevery same card issuing bank 2 b. The issuing bank 2 b receives theauthorization request and sends a response back to the processor of themerchant's acquiring bank 5 with a response code, whereupon theprocessor of the merchant's acquiring bank 5 forwards the response tothe trusted intermediary system 4. The trusted intermediary system 4then forwards the response to the merchant's system where it isinterpreted and a relevant response is relayed back to the cardholderand the merchant. Subsequent clearing and settlement are handled in aconventional manner, and involves the acquiring bank 5 depositing thetotal of the approved funds in to the merchant's nominated account. Itwill be appreciated that the communications associated with thesettlement part of the process may be effected by either single or dualmessage implementations.

Whilst the foregoing example describes operation of the payment system 1in relation to a single payment authorization request emanating from thetrusted intermediary system 4, the system 1 can also be used for aplurality of payment authorization requests. The trusted intermediarysystem 4 could conduct a consolidated account identification procedure,which includes redirecting the user U1 to the identified issuing bank soas to perform a single afore-described account identification requestprocedure for all subsequent payment authorization messaging with theacquiring bank 5 processor. The user U1 would perform the accountidentification request procedure prior to the generation of each of saidpayment authorization requests and sending of same to the acquiring bank5 processor. Alternatively the trusted intermediary system 4 couldredirect the user to conduct individual account identificationprocedures, one for each payment authorization request.

FIG. 2 shows an alternative embodiment of the payment system, in whichthe system 1 comprises a merchant Internet Payment Service Provider(merchant IPSP system), which is a payment gateway selected by themerchant for the purposes of conducting secure business on the Internet.A merchant IPSP system 3 provides a system that passes card data,authorization requests, and authorization responses over the Internetusing encryption technology. The transaction information is sent via themerchant IPSP system 3 to the card scheme system 7 where the validity ofthe card is checked and the availability of funds on that account isverified. An authorization code is returned to the acquiring system 5and on to the merchant IPSP system 3; the authorization is encrypted bythe merchant IPSP system 3 and transmitted in encrypted form to thetrusted intermediary system 4, which sends a suitable response to theweb server of the merchant 1 a, this triggering fulfillment of theorder. Thus in this embodiment the merchant IPSP system 3 is involved intransmission of the account identification response to the processor ofthe acquiring bank 5. In a preferred embodiment, the trustedintermediary system 4 is embodied within a novel transactional entity,herein referred to as a trusted intermediary, which cooperates withother payment entities of the payment system 1 as will now be describedwith reference to FIG. 3 . The trusted intermediary 10 is shown as beingcapable of transmitting payment authorization requests to each of aplurality of different merchant IPSP systems 3 a, 3 b. Each of theonline merchant processing systems 1 a . . . 1 c is associated with oneof the merchant IPSP systems 3 a, 3 b, as indicated by the dotted lineL1 for one of the merchants 1 c, as well as being associated with one ofthe acquiring banks 5 b, as indicated by the dotted line L2, again formerchant 1 c. At least some of the merchant IPSP systems 3 a, 3 b can bearranged to transmit payment authorization requests to more than oneacquiring bank: this reflects the fact that more than one merchant mayprocess their payments via a given merchant IPSP system, but each has anaccount with a different acquiring bank. Further, in accordance withembodiments of the invention, each merchant online processing system 1 a. . . 1 c has been modified to include, as payment option, “Pay fromCurrent Account” (PCA), this identifying a payment request via thetrusted intermediary system 4 embodied within the trusted intermediary10.

The trusted intermediary 10 holds data in a database DB1 correspondingto merchants and issuing banks that have registered with the trustedintermediary 10, together with transaction data. Since the trustedintermediary 10 interfaces with, rather than replaces, the merchant'sexisting merchant IPSP systems, it is the merchant account identifierthat is transmitted to the acquiring bank 5 b. Thus the relationship forsuch transactions is between the buyer and the online merchant, with theresulting benefit that the buyer is protected by the card scheme's rulesand by any applicable consumer protection. In addition, the merchantIPSP system can provide an online merchant with one or more additionalvarious transaction processing functions, for example settlement,handling of chargeback, handling of refunds, and transaction reporting,on behalf of the online merchant system. In addition, because paymentsystems according to embodiments of the invention involve the additionof the trusted intermediary 10 within an existing and known set ofprocessing entities, payments can be made according to conventionalmethods using arrangements of the first and second types described inthe background section in addition, or as an alternative to, via thetrusted intermediary 10.

Referring now to FIG. 4 , operation of the payment system 1 according toan embodiment of the invention will now be described. At step S401 theuser completes their shopping experience with Merchant Cs onlinemerchant system, initiates checkout using the merchant system, andproceeds to the virtual checkout, according to conventional methodsavailable through commonly available shopping cart and check-outsoftware packages such as are known to the skilled person. The userselects “Pay from Current Account” (PCA) as a payment option (stepS401), causing the merchant processing system 1 c to transmit a requestmessage to the trusted intermediary 10 (step S403); the request messagecomprises at least an amount of payment for the selected goods, themerchant account identifier and an identifier for the order. The trustedintermediary 10 then transmits a login URL to the consumer (step S405),prompting the user to commence the account selection process: the useris presented with a selection page, into which the user enters the nameand country code of the issuing bank they wish to use for thistransaction, in the manner described above with reference to FIG. 1(step S407). The trusted intermediary 10 then performs a lookup toobtain the URL of the relevant issuing bank and sends a redirectioninstruction to the user's browser, causing the user's browser to beredirected to the online login page corresponding to their identifiedissuing bank (step S409). The user U1 logs on using their online bankingcredentials (such as customer number, password, memorable personal dataetc.), causing the issuing bank software to send a list of eligiblepayment accounts and corresponding debit card details for selection bythe user U1 (step S411). As described above, the account and carddetails include the PAN for each respective account.

Upon selection of the desired account the trusted intermediary 10 sendsan authorization request message to the merchant's merchant IPSP system3 b, the request message comprising the selected account details, theamount of payment required and the merchant identifier (step S413). Themerchant IPSP system 3 b sends an authorization request to the relevantacquiring bank 5 b (step S414), prompting authorization (or otherwise)per conventional methods (step S415) and the transmission of a responsemessage from the acquiring bank 5 b to the merchant IPSP system 3 b(step S417). Assuming the response to comprise confirmation of thepayment having been authorized, at step S419, the merchant IPSP system 3b sends a payment success notification message to the trustedintermediary 10. This payment success notification message comprises areference for the card scheme authorization and a transaction identifierfor the card scheme transaction. Thereafter the trusted intermediary 10sends a payment success confirmation message to the merchant system 1 c(step S421), which prompts the merchant system to confirm the orderstatus to the user (step S423).

It will be appreciated from the foregoing that conventional merchantsystems (including their merchant IPSP system) require modifying toinclude “Pay from Current Account” (PCA) as a payment option and indeedto interface with the trusted intermediary 10. Accordingly the merchantIPSP system exposes a payment authorization service to the trustedintermediary 10 that allows payment and settlement for paymentinstruments (typically cards and bank accounts). Further it will beappreciated that because the trusted intermediary 10 integrates withmany merchant IPSP systems, it thus comprises a plurality of interfaceformats and protocols, each corresponding to a respective merchant IPSPsystem. Further, each merchant's system is configured with integrationsoftware components, e.g. in the form of plugins, which enables themerchant to integrate with the trusted intermediary 10 for the purposeof initiating a payment transaction using PCA as a payment method.

Details of the configuration and processing capabilities of the trustedintermediary system 4, referred to herein as PCA, will now be describedwith reference to FIG. 5 a . Thereafter, details of the trustedintermediary 10, referred to as “Secure System for Payment” (SSP) and inwhich the trusted intermediary system 4 is most convenientlyimplemented, will be described with reference to FIG. 5 b.

The trusted intermediary system 4 comprises presentation andconnectivity processing components 504, which are configured to transmitand manage various bank- and merchant-specific data; these processingcomponents will be explained in more detail below, but in overview theycomprise the following:

Bank Data Store:

The trusted intermediary system 4 stores bank identifiers, for examplein the form of Bank Identification Codes (BICs), or country, branch andbank names, for those issuing banks that have signed up to the “Pay fromCurrent Account” (PCA) service. For each listed issuing bank, thedatabase DB1 also holds data identifying a URL corresponding to theironline banking sign-on page.

Merchant Data Store:

The trusted intermediary system 4 stores merchant profile andregistration data. These data include a merchant account identifiertogether with a transactional and network identifier of the merchantIPSP system 3 b with which the merchant system is registered. These dataare held to enable the trusted intermediary system 4 to communicate withthe merchant IPSP system 3 b on behalf of the merchant system in themanner described above, and are collectively referred to as merchantIPSP system transmission data, or simply transmission data. In additionthe trusted intermediary system 4 comprises a payment authorizationservice through which the trusted intermediary system 4 effects paymentson behalf of the merchant. Further, because the trusted intermediarysystem 4 integrates with many merchant IPSP systems, it comprises aplurality of interface formats and protocols. Details of the relevantformats and protocols for each merchant IPSPS system are held in themerchant data store. Thus the afore-mentioned transmission datacomprises a mapping of a payment authorization request emanating from agiven online merchant system to an IPSP identifier, a network addressand/or network protocols that enable payment authorization requests tobe routed to the relevant merchant IPSP system.

It will therefore be appreciated that registration of any given merchantoffering the PCA service involves the merchant specifying the merchantIPSP system to which they subscribe. Conveniently the trustedintermediary system 4 can hold a set of records corresponding to activemerchant IPSP systems: each set of records can comprise networkidentifier and required communications protocols for storage in thedatabase DB1 by the trusted intermediary system 4. Thus duringregistration with the trusted intermediary system 4 the given onlinemerchant can select, e.g. via a drop down list coordinated by thepresentation components 504 of the trusted intermediary system 4, themerchant IPSP system to which the online merchant has subscribed; thecorresponding transmission data (or a link thereto) can then be storedin conjunction with the merchant records held in the database DB1.Accordingly, provided the given online merchant has specified itscorresponding merchant IPSP system in the manner just described, inresponse to receipt of a payment authorization request from the merchantsystem, the trusted intermediary system 4 can perform a suitable lookupfrom the database and retrieve the corresponding network identifier,protocol requirements etc. of the corresponding merchant IPSP system.

Application Programming Interfaces (API) Services Adaptor:

The trusted intermediary system 4 comprises an API Services Adaptor,which enables connectivity between the trusted intermediary system 4 andthe messaging infrastructure of the payment system 1. The adaptor isconfigured to manage the fulfillment of the trusted intermediary system4 requests to external services, such as payment authorizations tomerchant IPSP system 3 b and to expose a set of the trusted intermediarysystem 4 services that could be used by external functions such asmerchant IPSP system 3 b.

Transaction-Specific Components and Data:

The trusted intermediary system 4 stores transactional data such aspayment authorizations and settlements that are managed by the trustedintermediary system 4. In addition the trusted intermediary system 4 canstore audit data associated with merchant online activity as well asgeneral system activity.

It will be noted that the afore-mentioned components do not includemeans for storing user-specific data; this is because the user specifiesthe payment method in real time (i.e. at the point of effecting atransaction) and because the user is authenticated for the paymentservice by their online bank. Thus the trusted intermediary system 4does not need to hold user specific data. However, this is to beunderstood to be an optional aspect of the invention: the trustedintermediary system 4 could, and in fact in some embodiments (such asthose described below with reference to FIG. 11 ) is required to, storeuser credentials. Indeed when a user opts to make use of alternativefunctionality provided by the trusted intermediary 10 (referred to belowas “SSP” service), user data will be received and held thereby. Theassociated functionality provided by the trusted intermediary 10 isdescribed below with reference to FIG. 5 b.

Remaining with the arrangement shown in FIG. 5 a , and as mentionedabove, the trusted intermediary system 4 is preferably embodied as a webapplication server, for example as a J2EE compliant application server501 which manages and provides access to the common business logic ofthe platform, and a web server & J2EE servlet engine 503, which acts asthe entry point for external HTTP requests to the trusted intermediarysystem 4 from merchants and from users' browsers. The web server andservlet engine 503 comprises presentation components, which expose webservices-based payment APIs or API wrappers to merchant systems. Inaddition, the web server and servlet engine 503 comprises theafore-mentioned presentation processing components 504 which areconfigured to generate and manage the interface to merchants and banksas described above.

The J2EE Application Server 501 manages all the business logic for theweb platform and applications. The business logic comprises functionalsoftware components 511 a, 511 b, which can be implemented as, forexample, Session EJBs (Enterprise Java Beans). These functional groupsinclude, e.g. payment services logic, and fraud and security servicemodules; in addition the server 501 comprises objects implemented as EJB3.0 specified Java objects 511 a, 511 b that provide access to staticand persistent data stored in DB1 such as audit data and transactiondata described above. The trusted intermediary system 4 furthercomprises web services in the form of wrappers that expose Session EJBsto other elements of the payment system 1. More specifically, thefunctional objects 511 f, 511 g interoperate with external serviceenablers such as fraud services 515 a, among others. These applicationserver components 511 f, 511 g communicate with the applicationcomponents via a set of APIs, referred to generically as such inrelation to part 513 a. When implemented as a web server, data betweenthe elements of the payment system 1 (i.e. those shown in FIGS. 3 and 4) and the trusted intermediary system 4 are transmitted using a securemechanism, e.g. via the HTTP over Secure Socket Layer protocol (HTTPS).

As mentioned above, in addition to coordinating account selection by theuser U1 in the manner described above, and thus incorporating thetrusted intermediary system 4, the trusted intermediary 10 includesfunctionality that enables the user U1 to select from a plurality ofpreconfigured accounts in addition, or as an alternative, to specifyinga transactional account on a per transaction basis. This functionalityis made available to a user via a service referred to herein as “SecureSystem of Payment” (SSP). As will be described in more detail below, thedatabase DB1 can hold a set of payment details for the user in the formof a stored set of records conveniently referred to as a remote store,or user wallet; users can add details of cards and accounts that theycan select to make payment for a transaction, causing the trustedintermediary 10 to update the contents of the user's wallet. Thisenables the user to select a payment method on a per transaction basis,whilst removing the requirement for the user to provide payment detailsto individual merchants. Thus, provided merchants subscribe to thetrusted intermediary 10, users only have to submit their respectivepayment details once, to a single entity. This has the benefit ofreducing the risk of fraud that may be incurred in relation toconventional payment systems that require the user U1 to enter theircard payment details via the merchant's system.

Also as described above, the trusted intermediary 10 is connected toissuing bank systems 2 a, 2 b. This connection facilitates verificationof the cardholder (buyer) when adding a payment instrument to theirwallet using the well-known 3-D Secure authentication mechanism. Theprotocol for 3-D Secure is documented in U.S. patent application Ser.No. 10/156,271, published under publication number US2002/0194138 in thename of Visa International service Association, the content of which isincorporated by reference herein in its entirety. The protocol usesmessages (typically XML messages) sent over Secure Sockets Layer (SSL)connections, as is documented in the afore-mentioned patent publicationas the Payer Authentication Service (PAS). This service may be employedwhen a payment instrument is added to the user's wallet, or when thetrusted intermediary 10 determines a given requested transaction tocorrespond to a predetermined level of risk, such as may be the case fortransactions involving shipping abroad of high-value goods etc. Themeans by which the risk assessment is performed and indeed a risk leveldetermined for a given transaction is described in more detail below.

The card scheme system 7 is communicatively connected to the trustedintermediary 10 as schematically shown by dotted line L3; this indicatesthe trusted intermediary 10 having subscribed to an account updatingservice (not labeled on FIG. 3 , but described with reference to FIG. 5b below as part 515 d) provided by the card scheme system 7 and thencereceive updated card information, e.g. when a card is lost, is stolen orhas expired, and thus has been re-issued to the user. An example of sucha service is the Visa Account Updater service (VAU), while another isthe MasterCard Automatic Billing Updater. In one arrangement theinterface to the account updating service provided by the card schemesystem 7 is batch oriented: the trusted intermediary 10 submits arequest or requests to the card scheme system 7, the request includingdetails of certain users registered with the system 10. A batchinterface is typically used (e.g. Secure File Transfer Protocol (SFTP)or Connect: Direct™) to send the request file(s) to the account updatingservice, which is responsible for gathering details of re-issued cards.After an interval the trusted intermediary 10 accesses the accountupdating service and collects the response file(s), thereafter updatingpayment instruments locally for the relevant subscribers to the SSPsystem. Alternatively the interface could be message-based, so thatindividual Primary Account Numbers can be verified or updated inreal-time. As an alternative to sending the request directly to the cardscheme system 7, the trusted intermediary 10 could emulate operation ofan online merchant send the request to the known acquiring bank systems5 a . . . 5 c, for subsequent forwarding to the card scheme system 7.

FIG. 5 b is a schematic illustration of components of the trustedintermediary 10. Since, in this arrangement, the trusted intermediarysystem 4 is embodied within the trusted intermediary 10 using web servertechnology, in one embodiment the trusted intermediary 10 is also a webserver. In order to provide the SSP service, the trusted intermediary 10comprises the following elements: User registration components and data:

When a consumer wishes to make use of the prestored payment instrumentfacility offered by the trusted intermediary 10, they are required tocomplete an account registration process that allows a user to create asaid “Secure System for Payment” (SSP) account. The account is requiredto be populated with appropriate data that can be used to make paymentsvia the SSP service from a merchant system offering the SSP service as apayment option.

Registration of the user with the trusted intermediary 10 can beperformed via any suitable interface, most conveniently, when thetrusted intermediary 10 is implemented as a web server, via a webbrowser. Once registered, each user has a profile associated therewith,which stores demographic and identification data for the user and can bemodified via the presentation components 504, while user transactiondata can be displayed for review by the user. In addition the user canhave address book entries, which hold shipping details; the presentationcomponents 504 enable the user to modify the shipping details. As shownin FIG. 5 b and explained in more detail below, in the case where thetrusted intermediary 10 is implemented as a web server, the presentationcomponents 504 interoperate with the user's browser to allow selectionand modification of the user data in the manner just described.

Registration can be effected via a number of channels:

-   -   Via “Secure System for Payment” (SSP) site—the user logs onto        the website of the trusted intermediary 10 and is presented with        a registration page designed to capture the user's identity and        preferred payment details    -   Re-direct from checkout—If the user is within the merchant's        online system and wishes to checkout using the “Secure System        for Payment” (SSP) option they will need to register if they        have not already done so. The consumer is re-directed to the        registration screens associated with the trusted intermediary 10        and then re-directed back to the merchant's online system    -   Register via online bank—assuming the trusted intermediary 10        comprises the necessary integration functionality, the user can        register for the “Secure System for Payment” (SSP) service from        within their bank's online account management.

User Authentication Components:

Authentication of a user into the SSP service for payment transactionscan be performed directly with the trusted intermediary 10 according toany one of the 3 known categories listed below, or via the user's onlinebank, in which case the user logs into their online banking account(using one of the three categories listed below), whereupon the bankingsystem software re-directs the user back to the trusted intermediary 10.

1-factor authentication—Something the user knows (e.g., a username andpassword, pass phrase, or personal identification number (PIN)) 2-factorauthentication—As 1 factor authentication, plus, something the user has(e.g., ID card, security token, software token, phone, or cell phone)3-factor authentication—As 2 factor authentication, plus, something theuser is or does (e.g., fingerprint or retinal pattern, DNA sequence(there are assorted definitions of what is sufficient), signature orvoice recognition, unique bio-electric signals, or another biometricidentifier)

An example of a mechanism to enable authentication is theafore-mentioned 3-D Secure service—facilitated by the trustedintermediary system 10, the issuing bank prompts the buyer for apassword that is known only to the bank and the buyer. Since themerchant does not know this password and is not responsible forcapturing it, it can be used by the issuing bank as evidence that thepurchaser is indeed their cardholder.

User Account Data:

As mentioned above, users can have a set of records e.g. in the form ofa remote store, or wallet, associated therewith, which stores details ofthe payment instruments entered by the user and whose details they wishto store in a permanent manner for retrieval and access via the trustedintermediary 10. The presentation components 504 enable the user toselect and add to/remove from the list of payment instruments.

Transaction-Specific Components and Data:

In addition to storing audit data associated with merchant onlineactivity, the trusted intermediary 10 can store user activity data.

Messaging Services:

The trusted intermediary 10 is configured with email agents, whichcompose and transmit emails for the purposes of email addressauthentication and user activation and purchase order confirmations. Theweb server and servlet engine 503 comprises presentation components,which expose web services-based payment APIs or API wrappers 506 tomerchant systems.

In addition to the business logic components 511 f, 511 g describedabove, the J2EE Application Server 501 comprises functional softwarecomponents 511 c . . . 511 e which interoperate with external serviceenablers 505 such as address validation services 515 a, emailapplications (including access to an email server) 515 b, 3-D Secureservices 515 c, account updating services 515 d, and fraud services 515e, among others. Consistent with the arrangement shown in FIG. 5 a , theapplication server components communicate with the applicationcomponents 515 a . . . 515 e via a set of APIs, referred to genericallyas such in relation to parts 513 a . . . 513 e.

In the case of the 3-D Secure service functional component 511 c, thiscomponent uses, or cooperates with, risk-based rules which are invokedin order to determine whether or not the component should be involved inthe interactions between the user and the trusted intermediary 10. Therules are typically configured under control of the fraud services 515e, and may, for example, specify that the 3-D Secure method should beinvoked when a user registers a payment instrument with the SSP service(to ensure that the user is the legitimate cardholder); for the firsttransaction that a buyer makes; for transactions exceeding a certainvalue; for transactions that involve shipping of goods outside of thebuyer's home territory; and for certain types of goods and/or services.Other events that may trigger the 3-D Secure service, including invokingthe service for all transactions, will be apparent to one skilled in theart.

Turning to the account updating (AU) functional component 511 d andcorresponding service 515 d provided by the card scheme system 7, the AUcomponent 511 d comprises routines for routinely reviewing expiry datesof payment instruments stored in individual user wallets in the databaseDB1, and submitting requests to the card scheme system 7 with details ofusers whose payment instruments are due to expire within a specifiedtime window. The AU component 51 Id subsequently accesses the accountupdating service 515 d and collects a response file generated thereby,and updates payment instruments in the relevant user wallets on thebasis of the content of the response file.

The processing steps described above with reference to FIG. 4 ,specifically the steps performed by the trusted intermediary system 4 toenable the user to select a transactional account for payment accordingto a first embodiment of the invention, will now be described in moredetail. Turning to

FIG. 6 , at step S6.1, the user selects “Payment from Current Account”(PCA) as the payment method and submits their selection to the merchantwebsite. This triggers a request from the merchant system, specificallyretrieval by the merchant system of the URL corresponding to the PCAservice from the trusted intermediary 10. This results in the merchantwebsite reloading its payment page with an iFrame, the content of whichcorresponds to the PCA URL, and subsequently the sending of a key orderand the creation of a secure session (step S6.3). Having received thePCA URL from the trusted intermediary 10, the user U1 selects the BankIdentity Code (BIC) by inputting bank identifiers such as country, bankand branch (step S6.5). The selection is then forwarded to the trustedintermediary system web application 501 (step S6.7), triggering theapplication 501 to check that the selected bank is a participant of thePCA service (step S6.9). Assuming this to be the case, the trustedintermediary system 4 retrieves the URL of the bank's sign-in page fromthe data stored in the database DB1 and sends this to the iFrame (stepS6.11), causing the user's browser to direct the user to their onlinebanking web page (step S6.13). It is to be noted that the user loggingonto their online banking account serves to authenticate them to thetrusted intermediary system 4—i.e. there is no need for a secondauthentication process with the intermediate payment processing entity10.

The user U1 then enters their online banking details (step S6.13);assuming sign in to be successful, the bank software activates aself-expiring token (step S6.15). The token can be used for any APIcalls as proof of authentication, and accordingly is returned to theiFrame, together with an instruction to redirect the iFrame back to thetrusted intermediary system 4 (step S6.17). The redirection instructiontriggers a request message to be sent to the trusted intermediary system4 application, instructing the trusted intermediary system 4 applicationto request a list of accounts for the user (step S6.19) from the bankingsoftware. Accordingly an API call to the online banking software is madeto obtain the list of accounts and PANs, using the authentication tokentransmitted to the trusted intermediary system 4 at step S6.17 (stepS6.21). Thereafter, a list of accounts is sent to the trustedintermediary system 4 application (step S6.23), which generates anaccount selection page for display to the user (step S6.25), enablingthe user to select an account and submit their selection to the trustedintermediary system 4 application (step S6.27). The trusted intermediarysystem application 501 then forwards the account selection to theissuing bank software, again using the bank token (step S6.29), togetherwith a request for the account identifier corresponding to the selectedaccount. In response the bank software returns the PAN number normallyassociated with the debit card linked to the user's account to thetrusted intermediary system 4 application (step S6.31)

Having received the PAN, the web server and servlet engine 503 sends thepayment details to the merchant's merchant IPSP system 3 b via a paymentauthorization service through which the trusted intermediary 10 effectssubmission of a payment demand on behalf of the merchant; this involvescreating an authorization request for receipt by the payment APIs 506,converting the payment authorization request into the API format of themerchant's API and transmitting the formatted request to the merchantIPSP system 3 b. A settlement request is also transmitted to the paymentAPIs 506, which performs conversion of the settlement request into theAPI format of the merchant's API and transmits same to the merchant IPSPsystem 3 b. It will be appreciated that the communication may beeffected by either single or dual message implementations. Theseformatting and transmission actions are recorded in the transaction datastore held by the trusted intermediary 10 corresponding to the merchantsystem.

Upon notification of authorization of the payment request, the webserver and servlet engine 503 transmits a return merchant URL to theiFrame, together with notification of successful authorization, causingthe iFrame to empty, reload with JavaScript code from the merchantsystem, and thus remove the iFrame and return the user to the merchant'swebsite. Finally, the merchant displays the successful payment page.

The process shown in FIG. 6 is particularly advantageous in that theuser is presented with their own bank branded sign-on page; in additionthe bank carries sole responsibility for authenticating the user, andcan therefore apply its own authentication methods and fields.Furthermore, because the bank software sends a token to the trustedintermediary system iFrame, and this is passed to the trustedintermediary system application 501, enabling the trusted intermediarysystem application to start a communication session with the issuingbank, the user is presented with a standardized interface for retrievingaccount identifiers and associated account identifiers from their bank.

In parallel with foregoing steps, the application server 501 can log theuser's activity and send same to the audit data store, while sendingcorresponding system and event information to a third party fraudnotification system (this is represented by one of the common serviceenablers 515 a shown in FIG. 4 ). The fraud notification systemcomprises, but is not limited to, a fraud risk engine, which performsanalysis of same so as to generate a risk score and a recommended actionfor the transaction; suitable fraud notification systems such as thatprovided by RSA™ in their fraud prevention suite are known and will notbe described in any more detail herein. The risk score and action arestored in the database DB1, in conjunction with the other transactiondetails for the merchant and the user.

Alternative methods for enabling the user to select an account fromtheir issuing bank are envisaged: examples of such alternative methodsare shown in FIGS. 7-10 . FIG. 7 differs from the embodiment shown inFIG. 6 in that the issuing bank sends an account selection URL inresponse to the user having submitted their sign-on details, causingrendering of the user's accounts under direct control of the bankingsoftware rather than via an API offered by the banking software. Thussteps 7.1-7.13 proceed per steps 6.1-6.13, then at step 7.15 the bankingsoftware sends an account selection URL to the iFrame of the trustedintermediary system loaded in the merchant's website. Once displayed,the user can select an account from those listed (step 7.17), whereuponthe selected account is submitted to the banking software (step 7.19)and the PAN number corresponding to the selected account is transmittedto the trusted intermediary system application (step 7.21). FIG. 8 showsan arrangement in which the interactions between the trustedintermediary system 4 and the issuing bank have been passed to a thirdparty such as RSA™ or Arcot™ the third party provides the services onbehalf of issuing banks. Steps 8.1-8.9 proceed as per steps 6.1-6.9; atstep 8.11 the trusted intermediary system 4 identifies the banks sign onURL as hosted by the third party from its configuration data, anddisplays this in the iFrame. The user subsequently inputs their sign indetails, which are transmitted to the third party (step 8.13). Inresponse, the third part hosting service creates a self-expiring tokenfor any subsequent API calls (step 8.14) and sends an account selectionURL to the iFrame for display to the user on the merchant's website.Steps 8.15-8.21 proceed as described with reference to steps 7.15-7.21of FIG. 7 .

FIG. 9 shows an arrangement in which the user provides their onlinebanking details to the trusted intermediary system 4, which subsequentlyuses the sign on information to automatically log onto the issuing bankand thence retrieve the list of accounts. In this arrangement thetrusted intermediary system application 503 acts as a mediator betweenthe online merchant system and the issuing bank. Steps 9.1-9.11 proceedas described with reference to FIG. 6 , but at step 9.13 the sign indetails are sent to the trusted intermediary system application 503,which retrieves the bank sign-in URL, populates same with the user'ssign in details received at step 9.13, and performs the sign in to theonline banking software on behalf of the user (steps 9.15, 9.17). Theaccount numbers are then transmitted to the trusted intermediary systemapplication 503 (step 9.19 a), which forwards same to the iFrametogether with notification of successful login (step 9.19 b). Theaccount selection page is displayed in the iFrame (step 9.21) and theuser's account selection is forwarded to the trusted intermediary systemapplication 503 for onward transmission to the issuing bank web server(steps 9.23, 9.25). Finally the PAN is sent from the issuing web serverto the trusted intermediary system application 503 (step 9.27).

FIG. 10 shows an arrangement in which an API is used by the trustedintermediary system application 503 to retrieve the list of accountsfrom the banking software. As for the FIG. 9 embodiment, the user isrequired to first select their bank, whereupon the trusted intermediarysystem application 503 provides a sign-on page for the user to entertheir online banking sign on details. A call is then made to the issuingbank to retrieve the list of accounts for the sign on informationprovided by the user.

In more detail, steps 10.1-10.13 proceed as described with reference toFIG. 6 , then at step 10.15, and in response to receipt of the user'ssign-on details, the issuing bank software generates an authenticationtoken, which is subsequently transmitted to the iFrame of the trustedintermediary system 4 (step 10.17). In response, the trustedintermediary system 4 sends a request for a list of accountscorresponding to the user (authenticated at step 10.15), the requestbeing accompanied by the authentication token. Assuming theauthentication token to match that generated at step 10.15, the accountlist is sent to the intermediary system application 503 (step 10.19 a),which temporarily stores the accounts (including account identifiers)and coordinates display thereof in the iFrame at the merchant's onlinesystem (10.19 b). Thus when the user selects an account from the list(step 10.21), this results in the intermediary system application 503identifying the corresponding PAN from the numbers stored in its ownlocal and temporary storage.

As a further alternative, the user could be authenticated by the trustedintermediary 10 and delegate the responsibility to the trustedintermediary 10 to effect a log onto the user's selected bank account.Logon could be performed on the basis of a suitable set of credentialssupplied by the user, such as a credit card number and/or expiry date,which the user could enter in real time or select from their stored carddetails, and which forms the basis of authentication of the user by theselected issuing bank. FIG. 11 is a generic flow diagram showing thesteps involved in effecting payment using a payment instrument selectedaccording to an embodiment of the invention under control of the “SecureSystem for Payment” (SSP) service: at step S1 1.1 the user selects the“pay and register” option from the merchant's online shopping software,whereupon the user is first required to create a SSP account byproviding personal information such as name, email address, a password,contact telephone number any possibly delivery address (step S1 1.2).These details are saved into the database, and the user is thenpresented with two options: either to pay by card or to pay from acurrent account. The branch labeled step 11.3 a corresponds genericallyto the process steps described with reference to FIGS. 1-5 a, 6-10,while step 11.3 b corresponds to the user selecting the option ofentering and storing details of a card to be used for the transaction.This latter alternative therefore makes use of the SSP functionality ofthe trusted intermediary 10 described with reference to FIG. 5 b , withthe presentation components 504 providing the user with an interface forentering card details and thence storing same in the database DB 1. Asmentioned above, the 3-D Secure component 511 c is preferably invokedwhen the user enters respective card details for storage in their walletand/or in response to certain transaction events.

Irrespective of the payment option selected the user is then prompted toverify that all their transaction details are correct, or to add/editthem by for example providing an alternative delivery address. The usercan then finalize the transaction. Once the payment selection processhas been completed, the trusted intermediary 10 proceeds with thetransaction as described, e.g. with reference to steps S413-S421 of FIG.4 , finishing the process with transmittal of a confirmation message tothe online merchant. From the foregoing it will be appreciated thatembodiments of the invention can be viewed as comprising several parts,namely a) invocation; b) authentication; c) account selection; and d)payment routing. As regards part a), the “Payment from Current Account”(PCA) option can be invoked either directly from the online merchant'swebsite, as described with reference to FIGS. 1-8 , or via the “SecureSystem for Payment” service (SSP), as described with reference to FIG.11 .

In relation to authentication of the user's request to select an accountfor payment, this can be performed under control of the selected issuingbank, using information held by the user's bank (FIGS. 1-8 ), or undercontrol of the trusted intermediary 10, which can optionally involve aregistration process (FIG. 11 ). In either case it will appreciated thatthere is no requirement for registration as such with the trustedintermediary, since the user is effectively authenticated uponsuccessful logging into their online bank account.

In relation to selection of an account for payment, a user may have aplurality of accounts within a given issuing bank and indeed may haveaccounts with a plurality of issuing banks. Thus the interface presentedto the user, whether it is direct from the online merchant's system, orvia the SSP service, is such that the user can identify their chosenissuing bank and indeed bank accounts therein. When authenticated by theissuing bank, the bank presents a list of accounts to the user, the userselects and sends the bank account details to the PCA service. Whenauthenticated by the SSP service, the SSP service presents a list ofaccounts, based on previously saved data, for selection by the user.

Turning finally to payment routing, as described with reference to FIGS.1-10 , a transaction can be effected using the supplied PAN via themerchant IPSP system associated with the buyer. As an alternative, thetransaction could be debited from the user's account and credited to themerchant account via a card scheme system or an acquiring bank system.As a further alternative, the transaction could be debited from theuser's account via an alternative account key and credited to themerchant account via an alternative account key.

The above embodiments are to be understood as illustrative examples ofthe invention. Further embodiments of the invention are envisaged. Forexample, whilst in the foregoing examples the trusted intermediary 10 isdescribed as receiving payment requests from online merchant systems,the trusted intermediary 10 could additionally or alternatively receivepayment requests from a merchant IPSP system in an arrangement in whichthe merchant IPSP system is providing checkout services to the user. Insuch embodiments, such merchant IPSP systems are modified to offer“Secure System for Payment” (SSP) as an additional payment option.Whilst in the above embodiments, the financial account identity is givenin the form of a PAN, other financial account identities may be used inthe alternative. For example, a user's International Bank Account Number(IBAN), or alternatively a bank identifier, which is preferably aninternational bank identifier such as country code and sort code, or BICcode, and an account number. However, a PAN format is preferred since itis in the format which is processed using existing card scheme payments.

Whilst in the above embodiments, a PAN permanently associated with auser's financial account is used, in the alternative, or in addition, anissuing bank system may provide, as account identifier responses,one-time-use PAN's which are generated for one-time use, and a largenumber of such one-time-use PAN's may be stored and mapped by theissuing bank system against a single financial account.

Further, in the above examples it is assumed that the starting point forthe process is the online merchant's website; however embodiments of theinvention could also be used in conjunction with effecting bill paymentsor other invoices, where the origin of the transaction would not be anonline merchant system. Traditional bill-payment type scenarios assume apush-payment from the buyer (the user) to the beneficiary, typicallythrough an Automated Clearing House (ACH), so the payment is initiatedby the buyer's (the payer's) issuing bank. Whilst the transaction isinitiated in this scenario from a starting point other than from amerchant system, the actual financial transaction is neverthelessentered in to the transaction processing environment by an agent of themerchant. Consequently, in financial terms it would be deemed apull-payment; however, since the payment is initiated by the buyer (thepayer), the user will perceive it as a push-payment. Further, whilstpreferred embodiments make use of iFrame web technology to navigate theuser to different web sites, it will be appreciated that standard webredirection can instead be employed. In such alternative arrangementsthe user's browser will be navigated away from and back to the trustedintermediary system 4 web site, depending on the entity (or rather theURL corresponding thereto) with which the user's browser iscommunicating at any point in time. For example, during authenticationand/or account selection by the user, the user's browser may beredirected by the SSP website to a website provided by, or on behalf of,the user's issuing bank, and once the user authentication and/or accountselection is completed, the user's browser may be redirected by theissuer bank website back to the SSP website.

In the foregoing, the term “system”, when applied to entities such asthe merchant system, the merchant IPSP system, the trusted intermediarysystem, the account identification system and other entities, should beunderstood to mean a data processing function, provided at one or morephysical sites, connected to other data processing functions via datacommunications links. Each function may be provided by a single dataprocessing node, for example a server computer, or a set of dataprocessing nodes providing fail-over backup to each other, such as acluster of server computers, and/or a set of interconnected dataprocessing nodes providing different modular sub-functions with respectto other members of the set, for example an interworking set ofdifferent server computers.

As will be appreciated from the foregoing, communications between thevarious entities comprising the payment system 1 proceed via a datacommunications network such as the Internet. Each of the entities of thepayment system 1 (the issuing bank; the account identification systemwithin the issuing bank, which is used to identify a current accountfrom which payment is to be deducted; the trusted intermediary system;the trusted intermediary; the acquiring bank processor; the merchantIPSP systems; and the online merchant systems) is identifiable via anetwork identifier such as an Internet Protocol (IP) address or othersuitable identifier.

Accordingly the communications network can comprise a fixed line networkcomprising one or more technologies i.e. a hybrid communication network;for example the network can comprise the Internet in conjunction withthe Public Switched Telephone Network (PSTN) and/or a mobilecommunication network capable of supporting, for example, one or more ofthe following communication protocols: GSM (Global System Mobile), WCDMA(Wideband Code Division Multiple Access), GPRS (General Packet RadioService). In addition to or instead of the mobile communication network,a local area network such as a Wireless Local area network (WLAN) orBlueTooth® (BT) and/or other technologies such as WiMax can be used tocarry part of the request and response messages. In this way, users caninteract with the online merchant systems using portable, remotedevices. The data communications network can be arranged to supportgeneric Internet access using any transport methods. In addition, or asan alternative, to sending confirmation messages as email messages,payment confirmation messages can be transferred as SMS-messages (ShortMessage Service), MMS-messages (Multi Media Service), WirelessApplication Protocol (WAP) pages, Internet pages, HTML (HypertextMark-up Language) pages, XHTML (extended HTML) pages, or IP-datagrams(Internet Protocol).

One of the embodiments described above relates to application of theinvention in relation to a bank account that has a card associatedtherewith; others do not require the bank account to be associated witha payment product of any type, while others still may involve a bankaccount associated with a payment product such as a mobile phone orbiometric information. Other applications are envisaged. It is to beunderstood that any feature described in relation to any one embodimentmay be used alone, or in combination with other features described, andmay also be used in combination with one or more features of any otherof the embodiments, or any combination of any other of the embodiments.Furthermore, equivalents and modifications not described above may alsobe employed without departing from the scope of the invention, which isdefined in the accompanying claims.

What is claimed is:
 1. A method comprising: receiving, by an issuingbank server in a payment transaction, a redirected web page from abrowser of a user system used by a user, the redirected web page comingfrom a URL of the web page from a trusted intermediary application,which receives a bank identifier from the browser accessing an onlinemerchant web server, retrieves the URL of the web page using the bankidentifier, and transmits the URL of the web page to the browser;receiving, by the issuing bank server from the user system, sign indetails of the user from the user system via the redirected web page;activating, by the issuing bank server, a self-expiring token;transmitting, by the issuing bank server, the self-expiring token to theuser system along with an instruction to re-direct an iFrame associatedwith the browser to the trusted intermediary application, and a requestto the trusted intermediary application for a list of accountsassociated with the user, thereby redirecting the iFrame associated withthe browser to the trusted intermediary application; receiving, by theissuing bank server, the self-expiring token, and the request for thelist of accounts associated with the user from the trusted intermediaryapplication in an API call from the trusted intermediary application tothe issuing bank server; transmitting, by the issuing bank server, thelist of accounts associated with the user to the trusted intermediaryapplication, the trusted intermediary application generating an accountselection page with the list of accounts and providing the accountselection page to the user system; receiving, by the issuing bank serverfrom the trusted intermediary application, a selection of an account inthe list of accounts obtained from the user system, and theself-expiring token; providing a credential to the trusted intermediaryapplication after receiving the selected account, wherein the trustedintermediary application provides the credential to a merchant internetpayment service provider computer, which generates an authorizationrequest message comprising the credential and transmits theauthorization request message to the issuing bank server forauthorization, receiving, by a web server and servlet engine associatedwith the trusted intermediary application, a notification of successfulauthorization of the authorization request message; transmitting, by theweb server and servlet engine associated with the trusted intermediaryapplication, a return merchant URL with the notification of successfulauthorization to the iFrame; and responsive to receiving the returnmerchant URL, emptying the iFrame, and reloading the iFrame withJavascript code to return the user to the online merchant web server. 2.The method of claim 1, wherein the credential is a debit card number. 3.The method of claim 2, wherein the debit card number is linked to theaccount held by the trusted intermediary application.
 4. The method ofclaim 1, further comprising: receiving, by the trusted intermediaryapplication, a bank selection from the user system.
 5. The method ofclaim 4, wherein receiving the bank selection is in response to the userselecting a bank on the user system in response to the user systeminteracting with the trusted intermediary application.
 6. The method ofclaim 1, wherein the list of accounts comprises a list of payment cardaccounts of the user maintained by the issuing bank server.
 7. Themethod of claim 1, wherein the user system is communicating with amerchant Website on the online merchant web server when the list ofaccounts is received by the user system.
 8. The method of claim 1,wherein the user system is a personal computer.
 9. The method of claim1, wherein the authorization request message is transmitted to theissuing bank server via an acquirer computer.
 10. The method of claim 1,wherein after the issuing bank server authorizes the paymenttransaction, the iFrame is removed from the browser.
 11. The method ofclaim 1, wherein the trusted intermediary application is part of atrusted intermediary system that has a database that holds data relatingto multiple merchants and issuer banks, together with transaction data.12. A system comprising an issuing bank server, the system comprising:one or more processors; and one or more non-transitory computer readablemedia, comprising code, executable by the one or more processors toperform a method comprising: receiving, in a payment transaction, aredirected web page from a browser of a user system, the redirected webpage coming from a URL of the web page from a trusted intermediaryapplication, which receives a bank identifier from the browser accessingan online merchant web server, retrieves the URL of the web page usingthe bank identifier, and transmits the URL of the web page to thebrowser; receiving, from the user system, sign in details of a user fromthe user system via the redirected web page; activating a self-expiringtoken; transmitting the self-expiring token to the user system alongwith an instruction to re-direct an iFrame associated with the browserto the trusted intermediary application, and a request to the trustedintermediary application for a list of accounts associated with theuser, thereby redirecting the iFrame associated with the browser to thetrusted intermediary application; receiving the self-expiring token, andthe request for the list of accounts associated with the user from thetrusted intermediary application in an API call from the trustedintermediary application to the issuing bank server; transmitting thelist of accounts associated with the user to the trusted intermediaryapplication, the trusted intermediary application generating an accountselection page with the list of accounts and providing the accountselection page to the user system; receiving, from the trustedintermediary application, a selection of an account in the list ofaccounts obtained from the user system, and the self-expiring token;providing a credential to the trusted intermediary application afterreceiving the selected account, wherein the trusted intermediaryapplication provides the credential to a merchant internet paymentservice provider computer, which generates an authorization requestmessage comprising the credential and transmits the authorizationrequest message to the issuing bank server for authorization, receivinga notification of successful authorization of the authorization requestmessage; transmitting a return merchant URL with the notification ofsuccessful authorization to the iFrame; and responsive to receiving thereturn merchant URL, emptying the iFrame, and reloading the iFrame withJavascript code to return the user to the online merchant web server.13. The system of claim 12, wherein the list of accounts comprises alist of payment card accounts, the list of payment card accountsincluding at least one debit card account.
 14. The system of claim 12,wherein the credential is a debit card number.